Situations arise when operating system (OS) software has to be upgrade on already deployed Information Technology (IT) systems such as collocated web servers, cloud servers, etc. (collectively referred to herein as servers). The servers described herein utilize UNIX operating systems and variants thereof such as FreeBSD, Linux, and the like. The servers can include generic media allocation/partitioning schemas where there is only place for one OS (Operating System) image. Specifically, the servers can include a single partition for <root> and a single partition for <usr> filesystems. Disadvantageously, when the current OS has to be upgraded in these configurations, this upgrade cannot be done online. First, this limitation is because, in order to run the upgrade procedure, the OS should be running, but this is the same live OS that is being upgraded and in the same location. Second, in case something goes wrong, for example, the OS image is in an intermediate state and the whole system becomes inoperable. Thus, conventionally, such upgrades must be implemented offline—such as via some special OS image that is sitting “aside” of the main media and after booting up is able to access such media and do operations required, e.g., an offline agent. The offline agent has to be imbedded at the server procurement stage or by some special means like Intelligent Platform Management Interface (IPMI) virtual drivers. There are several disadvantages based on the aforementioned limitations. A live system cannot be easily upgraded due to the need for OS to access in for live operating the same files that upgrade process has to change. If a live upgrade is possible, then there is large time window where media is in an intermediate inoperable state. Finally, such an upgrade is destructive which cannot be rolled back after the upgrade (at least not without going through the whole upgrade—or downgrade in this case—procedure as whole).